\chapter{Le paquetage \texttt{MCQReaderModel}}

Ce paquet est composé de l'ensemble des classes qui entreront dans la construction de l'arborescence des zones délimitées du \textsf{QCM}.

\section{Les classes du paquetage}

L'organisation des classes dans ce paquetage est selon le diagramme suivant:

\begin{figure}[H]
\centering
\includegraphics[width=\textwidth]{../images/MCQReaderModel.jpg}
\caption{Diagramme de classe du paquetage MCQReaderModel}
\label{diagramme_analyse}
\end{figure}
Toutes les classes de ce diagramme mises à part les classe \texttt{ModelManager}, \texttt{Rectangle} et \texttt{JTree} héritent de la classe \texttt{javax.swing.tree.DefaultMutableTreeNode} et ce en raison du fait qu'elles rentrent toutes dans la construction de l'arborescence des zones délimitées et doivent à priori avoir toutes les propriétés d'un noeud dans un arbre: accès au père, accès aux fils, supprimer un fils $\hdots$ 
\\
Nous expliquons sommairement à quoi correspond chaque classe puis nous expliquerons plus en détail le rôle essentiel de la classe \texttt{ModelManager} dans la génération du fichier modèle.

\subsection{La classe \texttt{PageNode}}

Dans l'arborescence des zones délimitées du \textsf{QCM}, les noeuds représentatifs des différentes pages du \textsf{QCM} sont instance de cette classe. On comprend donc que tout noeud instance de la classe \texttt{PageNode} sera ancêtre ou père direct des zones délimitées dans la page qu'il représente.   

\subsection{Les classes \texttt{Zone, Radio, Case, BitField, TextZone}}

Les classes \texttt{Radio, Case, BitField} et \texttt{TextZone}  sont toutes liées  à un rectangle. Ceci se traduit par le fait qu'elles héritent toutes de la classe \texttt{Zone} qui a pour attribut la classe \texttt{Rectangle}. Les instances de la classe \texttt{Rectangle} contenues dans les instances de ces différentes classes permettront de repérer pendant l'analyse les zones délimitées associées et qui sont reparties de la façon suivante:

\begin{dinglist}{70}
\item Les zones délimitées correspondant à un radio dans le \textsf{QCM} seront représentées dans l'arborescence par un noeud instance de la classe \texttt{Radio}
\item Les zones délimitées correspondant à une case dans le \textsf{QCM} seront représentées dans l'arborescence par un noeud instance de la classe \texttt{Case}
\item Les zones délimitées correspondant à une zone de texte dans le \textsf{QCM} seront représentées dans l'arborescence par un noeud instance de la classe \texttt{TextZone}
\item Les zones délimitées correspondant à un champ de bit dans le \textsf{QCM} seront représentées dans l'arborescence par un noeud instance de la classe \texttt{BitField}. Un champ de bit est un groupement de case alignées correspondant à un nombre en binaire et servant d' identifiant. Le bit correspondant a une case vaut $1$ si la case est noircie sinon vaut $0$.
\end{dinglist}

\subsection{Les classe \texttt{GroupNode, RadioGroup, CaseGroup}}

Les classes \texttt{Radiogroup} et \texttt{CaseGroup} ont les mêmes fonctionnalités. Dans l'arborescence des zones délimités les noeuds instance de ces classes représentent des questions et leurs fils représentent les différentes réponses possibles à cette question. \texttt{RadioGroup} correspond aux questions dont la réponse est représentée par un groupe de radios et \texttt{CaseGroup} celles dont la réponse la réponse à une question représentée par un groupe de cases. Compte tenu du fait qu'elles ont les mêmes fonctionnalités, nous faisons hériter ces deux classes de la classe \texttt{GroupeNode} qui est quant à elle abstraite. 
\\
\\
\textbf{\underline{Remarque}:} L'utilité de définir deux classes qui en réalité joue le même rôle intervient dans le cas où on voudrait  distinguer la réponse à une question représentée par un groupe de radios de celle à une question représentée par un groupe de cases. Ce qui est tout à fait logique dans la mesure où dans un groupe de radios, un seul doit être noirci et que dans un groupe de cases plusieurs peuvent être noircies. 

\subsection{La classe \texttt{ModelManager}}\label{model}

Cette classe primordiale dans la génération du fichier modèle fournit deux méthodes, l'une permettant de passer de l'arborescence au fichier modèle et l'autre permettant de faire l'opération inverse. Elle a pour attribut une instance de la classe \texttt{JTree} qui est l'arborescence des zones délimitées du \texttt{QCM}.
\\
\\
\textbf{De l'arbre des zones délimitées vers le fichier modèle}
\\
Cette première opération se fait à l'aide de la classe \texttt{java.beans.XMLEncoder}. Pour ce qui est de générer un fichier modèle, cette classe est plus adaptée parce qu'elle est simple à utiliser et surtout parce que le fichier \textsf{xml} est optimisé: les attributs des classes ayant leurs valeurs par défaut c'est à dire des attributs non modifiés pendant la génération du modèle, n'apparaissent pas  dans le fichier \textsf{xml}. Notons aussi l'avantage du format \textsf{xml} qui est d'être compréhensible par l'esprit humain, ce qui n'est pas le cas avec les fichiers binaires.
\\
\\
\textbf{Du fichier modèle vers l'arbre des zones délimitées}
\\
De la même manière que la classe \texttt{ModelManager} fournit une méthode qui permet de passer de l'arbre des zones délimitées au fichier modèle en format \textsf{xml} dans notre cas, elle fournit également l'opération inverse qui consiste à passer du fichier modèle à l'arbre des zones délimitées et elle est prise en charge par la classe \texttt{java.beans.XMLDecoder}.


\section{Le format du fichier modèle} 

Nous utilisons le format \textsf{xml} pour des raisons définies dans la partie \ref{model} mais toute autre forme de sauvegarde du fichier modèle est envisageable à condition de fournir une fonction qui permettrait de reconstruire l'arbre à partir du fichier modèle. Nous avons travaillé de sorte à rendre le code du logiciel indépendant du fichier modèle. Le seul lien entre les deux fonctionnalités du logiciel (Création de fichier modèle et analyse) est l'arbre construit des zones délimitées: pendant l'analyse l'on prend les informations depuis l'arborescence et non directement dans le fichier modèle de sorte à rendre l'analyse indépendante du format du fichier modèle.
\\
\\
\textbf{Remarque}: pour continuer à utiliser notre système de génération et de chargement du fichier modèle, il est impératif que toutes les classes qui rentrent dans la construction de l'arborescence  des zones délimitées du \textsf{QCM} respectent le format \textsf{bean}. Ainsi, elles doivent contenir un constructeur par défaut et des méthodes de la forme setXXX(), getXXX() ou isXXX() où XXX serait un attribut de la classe afin que l'attribut XXX apparaisse dans le fichier \textsf{xml}.

\chapter{Le paquetage \texttt{CMQReaderAnsweredAnalyze}}
Ce paquetage  sert à l'analyse du {\sf QCM} et correspond à la deuxième fonctionnalité du logiciel. Après avoir défini et stocké les informations sur des zones du \textsf{QCM} vide dans un fichier modèle, cette deuxième partie du logiciel vérifie le contenu de ces zones dans le \textsf{QCM} rempli pour ensuite générer un fichier résultat au format \textsf{CSV}.

\section{Les classes de \texttt{CMQReaderAnsweredAnalyze} }
L'organisation des classes entre elles dans ce paquetage est à l'image  du  diagramme suivant:

\begin{figure}[H]
\centering
\includegraphics[width=\textwidth]{../images/MCQReaderAnsweredAnalyze.jpg}
\caption{Diagramme de classe du paquetage CMQReaderAnsewredAnalyse}
\label{diagramme_analyse}
\end{figure}

Nous commençons d'abord par une sobre présentation des différentes classes puis nous parlerons plus en profondeur de comment elles interagissent entre elles.

\subsection{La classe \texttt{DialogBeforeAnalyzis}}

Comme son nom l'indique en français ``dialogue avant l'analyse'', cette classe s'occupe de tout ce qui est communication avec l'utilisateur avant de lancer l'analyse. Ce qui  se traduit par l'estimation du  temps que l'analyse prendra, la mise en place  d'un bilan sur le nombre de \textsf{QCM} et de pages qui seront analysés et  la confirmation  par  l'utilisateur au vu de toutes ses informations   du lancement l'analyse.  

\subsection{La classe \texttt{Coordonnees}}

Cette classe a pour vocation le calcul des coordonnées, c'est à dire tous les calculs à effectuer pour retrouver les coordonnées exactes d'une zone à analyser à partir des informations tirer de l'arbre des zones délimitées.

\subsection{La classe \texttt{AnalyzeSelectedZone}}

Cette classe  vérifie si une zone est cochée. 
Pour ce faire, il retourne \texttt{VRAI}(la zone est cochée)
si le pourcentage de pixels noirs dans la zone atteint ``$35$\%" 
sinon retourne \texttt{FAUX}. 

\subsection{La classe \texttt{ImageManager}}

Cette classe se charge de fournir pendant l'analyse l'image de la page en cours d'analyse de sorte à ce que l'analyse d'une zone se fasse exactement dans la page où elle a été définie pendant la génération du fichier modèle.

\subsection{La classe \texttt{PrintAnalyzisResult}}

Cette classe s'occupe de la dernière phase de l'analyse qui consiste à récupérer les résultats de l'analyse  et de les traduire en chaîne de caractères  dans un fichier d'extension  \textsf{CSV} d'où son nom <<printAnalyzisResult>>.

\subsection{La classe \texttt{BarreDeProgression}}

Pendant l'analyse, une barre de progression s'affiche correspondant à l'état d'avancement de celle-ci. Cette barre est la traduction graphique du nombre de pages déjà analysées sur le nombre totale de pages à analyser. On aurait pu faire mieux en considérant plutôt le nombre de zones analysées par rapport au nombre total de zones à analyser.

\subsection{La classe \texttt{AnalyseCancelException}}

Cette classe contient divers messages d'erreur correspondant à ses différentes méthodes. Elle est gérée comme une exception, elle est levée si une erreur , par exemple lorsque l'on tape une lettre à la place d'un chiffre, est occulée. 

\subsection{La classe \texttt{AnsweredCMQAnalyse}}

Cette classe \textsf{coordonnes} les actions des classes du paquetage entre elles. Elle contient toutes les autres classes et les fait interagir de façon cohérente.

\section{L'interaction entre les classes}

Au travers des brèves descriptions de chaque classe du paquetage, on voit qu'un schéma se dessine déjà. Schéma selon lequel la classe \texttt{PrintAnalyzisResult} fait un parcours de l'arbre des zones délimitées, récupère les zones et l'image de la page en cours d'analyse (en faisant notamment appel à la classe ImageManager) et les passent à la classe \texttt{AnalyzeSelectedZone} qui lui répond par \texttt{VRAI} si la zone est cochée ou \texttt{FAUX} sinon. Le résultat de l'analyse est imprimé dans le fichier \textsf{CSV}. Ainsi la classe \texttt{PrintAnalyzisResult} communique-t-elle  directement avec la classe \texttt{AnalyzeSelectedZone} et la classe \texttt{ImageManager}.
\\
Juste avant de lancer l'analyse, la classe \texttt{AnsweredCMQAnalyse} établit un dialogue avec l'utilisateur par le biais de la classe \texttt{DialogBeforeAnalyzis} avant de faire appel à la classe 
\\
\texttt{PrintAnalyzisResult} qui imprime le résultat en format \textsf{CSV}. Une barre de progression est lancée pendant l'analyse.   

\section{Commentaire sur le travail fourni et améliorations possibles}

Sur certaines parties du projet, le travail réalisé est plus que satisfaisant, sur d'autres parties des améliorations restent envisageables et enfin des parties restent inachevées.

\subsection{Le fichier résultat}

Le fichier \textsf{CSV} étant une suite de données séparées par des virgules (ou des points virgule, ou des espaces $\hdots $) l'implémentation est un peu libre. Tout dépend de la façon dont l'utilisateur voudrait traiter le fichier \textsf{CSV}. Par exemple dans notre cas nous sommes parti d'un fichier modèle où le résultat de l'analyse d'un \textsf{QCM} tenait sur plusieurs lignes dans le fichier \textsf{CSV} ce qui a été désapprouvé par le client qui voudrait que les résultat de l'analyse d'un \textsf{QCM} tienne sur une seule ligne.  
\\
\\
\textbf{\underline{Dilemne}: forme du fichier modèle et analyse des zones}
\\
Dans notre implémentation, on génère le fichier modèle en même temps que l'analyse les zones. Ce qui s'est avéré par la suite maladroit dans la mesure où à chaque fois qu'on décidait de changer la forme du fichier \textsf{CSV} il fallait aussi toucher à l'algorithme d'analyse des zones et allait à l'encontre de l'approche modulaire que nous avons voulu adopter.
\\
\\
\textbf{\underline{Amélioration}: dissocier l'algorithme d'analyse du fichier modèle}
\\
Comme soulevé précédemment, une meilleure façon de faire serait de dissocier l'algorithme d'analyse de  l'algorithme de génération du fichier résultat. On pourrait par exemple sauvegarder le résultat de l'analyse sous forme de structure de données et mettre en place un algorithme qui construit le fichier résultat à partir de la structure de stockage du résultat de l'analyse et pourquoi ne pas en faire tout un module.
\\
\\
\textbf{Remarque:} En dissociant l'algorithme d'analyse des zones de l'algorithme de génération du fichier résultat, pour un même résultat d'analyse on pourrait définir plusieurs algorithmes de génération du fichier résultat et ainsi proposer à l'utilisateur plusieurs formes de sauvegarde du fichier résultat parmi lesquelles il pourrait choisir.

\subsection{La barre de progression}

Une barre de progression  est en cours d'implémentation  et n'est pas totalement achevée dans la mesure où on a pas eu assez de temps pour utiliser la communication entre un processus parent et un thread fils de sorte à ce que la père et le fils se donnent mutuellement la main pour que le fils d'une part affiche l'état du père et que le père d'autre part continue son exécution.
